<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Reading and Writing documents | ElasticSearch 7.7 权威指南中文版</title>
	<meta name="keywords" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <meta name="description" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
	<script>
	var _link = 'docs-replication.html';
    </script>
</head>
<body>
<div class="main-container">
    <section id="content">
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.7/docs-replication.html" rel="nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/7.7/docs-replication.html</a>, 原文档版权归 www.elastic.co 所有<br/>本地英文版地址: <a href="../en/docs-replication.html" rel="nofollow" target="_blank">../en/docs-replication.html</a></div>
                        <!-- start body -->
                  <div class="page_header">
<strong>重要</strong>: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html" rel="nofollow">当前版本文档</a>。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="rest-apis.html">REST APIs</a></span>
»
<span class="breadcrumb-link"><a href="docs.html">Document APIs</a></span>
»
<span class="breadcrumb-node">Reading and Writing documents</span>
</div>
<div class="navheader">
<span class="prev">
<a href="docs.html">« Document APIs</a>
</span>
<span class="next">
<a href="docs-index_.html">Index API »</a>
</span>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="docs-replication"></a>Reading and Writing documents<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h2>
</div></div></div>
<h4>
<a id="_introduction"></a>Introduction<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>Each index in Elasticsearch is <a class="xref" href="scalability.html" title="可伸缩性和弹性：集群，节点和分片">divided into shards</a>
and each shard can have multiple copies. These copies are known as a <em>replication group</em> and must be kept in sync when documents
are added or removed. If we fail to do so, reading from one copy will result in very different results than reading from another.
The process of keeping the shard copies in sync and serving reads from them is what we call the <em>data replication model</em>.</p>
<p>Elasticsearch’s data replication model is based on the <em>primary-backup model</em> and is described very well in the
<a href="https://www.microsoft.com/en-us/research/publication/pacifica-replication-in-log-based-distributed-storage-systems/" class="ulink" target="_top">PacificA paper</a> of
Microsoft Research. That model is based on having a single copy from the replication group that acts as the primary shard.
The other copies are called <em>replica shards</em>. The primary serves as the main entry point for all indexing operations. It is in charge of
validating them and making sure they are correct. Once an index operation has been accepted by the primary, the primary is also
responsible for replicating the operation to the other copies.</p>
<p>This purpose of this section is to give a high level overview of the Elasticsearch replication model and discuss the implications
it has for various interactions between write and read operations.</p>
<h4>
<a id="_basic_write_model"></a>Basic write model<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>Every indexing operation in Elasticsearch is first resolved to a replication group using <a class="xref" href="docs-index_.html#index-routing" title="Routing">routing</a>,
typically based on the document ID. Once the replication group has been determined,
the operation is forwarded internally to the current <em>primary shard</em> of the group. The primary shard is responsible
for validating the operation and forwarding it to the other replicas. Since replicas can be offline, the primary
is not required to replicate to all replicas. Instead, Elasticsearch maintains a list of shard copies that should
receive the operation. This list is called the <em>in-sync copies</em> and is maintained by the master node. As the name implies,
these are the set of "good" shard copies that are guaranteed to have processed all of the index and delete operations that
have been acknowledged to the user. The primary is responsible for maintaining this invariant and thus has to replicate all
operations to each copy in this set.</p>
<p>The primary shard follows this basic flow:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
Validate incoming operation and reject it if structurally invalid (Example: have an object field where a number is expected)
</li>
<li class="listitem">
Execute the operation locally i.e. indexing or deleting the relevant document. This will also validate the content of fields
and reject if needed (Example: a keyword value is too long for indexing in Lucene).
</li>
<li class="listitem">
Forward the operation to each replica in the current in-sync copies set. If there are multiple replicas, this is done in parallel.
</li>
<li class="listitem">
Once all replicas have successfully performed the operation and responded to the primary, the primary acknowledges the successful
completion of the request to the client.
</li>
</ol>
</div>
<h5>
<a id="_failure_handling"></a>Failure handling<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h5>
<p>Many things can go wrong during indexing — disks can get corrupted, nodes can be disconnected from each other, or some
configuration mistake could cause an operation to fail on a replica despite it being successful on the primary. These
are infrequent but the primary has to respond to them.</p>
<p>In the case that the primary itself fails, the node hosting the primary will send a message to the master about it. The indexing
operation will wait (up to 1 minute, by <a class="xref" href="index-modules.html#dynamic-index-settings" title="Dynamic index settings">default</a>) for the master to promote one of the replicas to be a
new primary. The operation will then be forwarded to the new primary for processing. Note that the master also monitors the
health of the nodes and may decide to proactively demote a primary. This typically happens when the node holding the primary
is isolated from the cluster by a networking issue. See <a class="xref" href="docs-replication.html#demoted-primary">here</a> for more details.</p>
<p>Once the operation has been successfully performed on the primary, the primary has to deal with potential failures
when executing it on the replica shards. This may be caused by an actual failure on the replica or due to a network
issue preventing the operation from reaching the replica (or preventing the replica from responding). All of these
share the same end result: a replica which is part of the in-sync replica set misses an operation that is about to
be acknowledged. In order to avoid violating the invariant, the primary sends a message to the master requesting
that the problematic shard be removed from the in-sync replica set. Only once removal of the shard has been acknowledged
by the master does the primary acknowledge the operation. Note that the master will also instruct another node to start
building a new shard copy in order to restore the system to a healthy state.</p>
<p><a id="demoted-primary"></a>While forwarding an operation to the replicas, the primary will use the replicas to validate that it is still the
active primary. If the primary has been isolated due to a network partition (or a long GC) it may continue to process
incoming indexing operations before realising that it has been demoted. Operations that come from a stale primary
will be rejected by the replicas. When the primary receives a response from the replica rejecting its request because
it is no longer the primary then it will reach out to the master and will learn that it has been replaced. The
operation is then routed to the new primary.</p>
<div class="sidebar">
<div class="titlepage"><div><div>
<p class="title"><strong>What happens if there are no replicas?</strong></p>
</div></div></div>
<p>This is a valid scenario that can happen due to index configuration or simply
because all the replicas have failed. In that case the primary is processing operations without any external validation,
which may seem problematic. On the other hand, the primary cannot fail other shards on its own but request the master to do
so on its behalf. This means that the master knows that the primary is the only single good copy. We are therefore guaranteed
that the master will not promote any other (out-of-date) shard copy to be a  new primary and that any operation indexed
into the primary will not be lost. Of course, since at that point we are running with only single copy of the data, physical hardware
issues can cause data loss. See <a class="xref" href="docs-index_.html#index-wait-for-active-shards" title="Active shards">Active shards</a> for some mitigation options.</p>
</div>
<h4>
<a id="_basic_read_model"></a>Basic read model<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>Reads in Elasticsearch can be very lightweight lookups by ID or a heavy search request with complex aggregations that
take non-trivial CPU power. One of the beauties of the primary-backup model is that it keeps all shard copies identical
(with the exception of in-flight operations). As such, a single in-sync copy is sufficient to serve read requests.</p>
<p>When a read request is received by a node, that node is responsible for forwarding it to the nodes that hold the relevant shards,
collating the responses, and responding to the client. We call that node the <em>coordinating node</em> for that request. The basic flow
is as follows:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
Resolve the read requests to the relevant shards. Note that since most searches will be sent to one or more indices,
they typically need to read from multiple shards, each representing a different subset of the data.
</li>
<li class="listitem">
Select an active copy of each relevant shard, from the shard replication group. This can be either the primary or
a replica. By default, Elasticsearch will simply round robin between the shard copies.
</li>
<li class="listitem">
Send shard level read requests to the selected copies.
</li>
<li class="listitem">
Combine the results and respond. Note that in the case of get by ID look up, only one shard is relevant and this step can be skipped.
</li>
</ol>
</div>
<h5>
<a id="shard-failures"></a>Shard failures<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h5>
<p>When a shard fails to respond to a read request, the coordinating node sends the
request to another shard copy in the same replication group. Repeated failures
can result in no available shard copies.</p>
<p>To ensure fast responses, the following APIs will
respond with partial results if one or more shards fail:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<a class="xref" href="search-search.html" title="Search API">Search</a>
</li>
<li class="listitem">
<a class="xref" href="search-multi-search.html" title="Multi Search API">Multi Search</a>
</li>
<li class="listitem">
<a class="xref" href="docs-bulk.html" title="Bulk API">Bulk</a>
</li>
<li class="listitem">
<a class="xref" href="docs-multi-get.html" title="Multi get (mget) API">Multi Get</a>
</li>
</ul>
</div>
<p>Responses containing partial results still provide a <code class="literal">200 OK</code> HTTP status code.
Shard failures are indicated by the <code class="literal">timed_out</code> and <code class="literal">_shards</code> fields of
the response header.</p>
<h4>
<a id="_a_few_simple_implications"></a>A few simple implications<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>Each of these basic flows determines how Elasticsearch behaves as a system for both reads and writes. Furthermore, since read
and write requests can be executed concurrently, these two basic flows interact with each other. This has a few inherent implications:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
Efficient reads
</span>
</dt>
<dd>
Under normal operation each read operation is performed once for each relevant replication group.
Only under failure conditions do multiple copies of the same shard execute the same search.
</dd>
<dt>
<span class="term">
Read unacknowledged
</span>
</dt>
<dd>
Since the primary first indexes locally and then replicates the request, it is possible for a
concurrent read to already see the change before it has been acknowledged.
</dd>
<dt>
<span class="term">
Two copies by default
</span>
</dt>
<dd>
This model can be fault tolerant while maintaining only two copies of the data. This is in contrast to
quorum-based system where the minimum number of copies for fault tolerance is 3.
</dd>
</dl>
</div>
<h4>
<a id="_failures"></a>Failures<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>Under failures, the following is possible:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
A single shard can slow down indexing
</span>
</dt>
<dd>
Because the primary waits for all replicas in the in-sync copies set during each operation,
a single slow shard can slow down the entire replication group. This is the price we pay for the read efficiency mentioned above.
Of course a single slow shard will also slow down unlucky searches that have been routed to it.
</dd>
<dt>
<span class="term">
Dirty reads
</span>
</dt>
<dd>
An isolated primary can expose writes that will not be acknowledged. This is caused by the fact that an isolated
primary will only realize that it is isolated once it sends requests to its replicas or when reaching out to the master.
At that point the operation is already indexed into the primary and can be read by a concurrent read. Elasticsearch mitigates
this risk by pinging the master every second (by default) and rejecting indexing operations if no master is known.
</dd>
</dl>
</div>
<h4>
<a id="_the_tip_of_the_iceberg"></a>The Tip of the Iceberg<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/docs/data-replication.asciidoc">edit</a>
</h4>
<p>This document provides a high level overview of how Elasticsearch deals with data. Of course, there is much much more
going on under the hood. Things like primary terms, cluster state publishing, and master election all play a role in
keeping this system behaving correctly. This document also doesn’t cover known and important
bugs (both closed and open). We recognize that <a href="https://github.com/elastic/elasticsearch/issues?q=label%3Aresiliency" class="ulink" target="_top">GitHub is hard to keep up with</a>.
To help people stay on top of those, we maintain a dedicated <a href="https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html" class="ulink" target="_top">resiliency page</a>
on our website. We strongly advise reading it.</p>
</div>
<div class="navfooter">
<span class="prev">
<a href="docs.html">« Document APIs</a>
</span>
<span class="next">
<a href="docs-index_.html">Index API »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>